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As a result of a recent conversation with Butler Lampson on the topic of I/O on Wildflov^er, a 
number of issues concerning the extent to which Wildflowcr meets tiic current OIS PrinccOps arose. 
The tone of the issues is that the current PrinccOps may not be suitable for the more modest 
processors in the OIS luie. These issues all have to do with the question of whether or not the 
buffer addresses in CSBs and lOCBs should be virtual or real. 

As I see it the issues are: 

1) If the bufFer addresses are virtual, when are they bound to real addresses? The current 
PrinccOps is silent on this point and might lead one to believe that it is possible to race map 
changes against the I/O itself. The current implementation of the DO supports this to a large extent 
by means of its mapping hardware. I believe that this is excessive and useless generality and that 
virtual addresses should be considered bound to real address no later than the fetch of the lOCB 
for processing. Any map changes between that point in time and the completion of the lOCB 
would lead to undefined operation. I could easily be persuaded that the map should not be 
changed under an lOCB while it was chained on the CSB for processing. 

2) If the buffer addresses are virtual and are bound (translated) at the fetch of the lOCB, what 
happens when the buffer crosses a page boundry? 

Tliere seem to be three possibilities: 

a) The processor is fast enough or powerful enough to rebind the incremented virtual 
address at each page crossing. (The l5o uses a more extreme measure in that the memory 
control is powerful to rebind at each (I/O) memory reference.) This may be too severe a 
constraint for small OIS processors. 

b) Buffers are not permitted to cross page boundries. (We are now coming to Ihe view that 
buffers should not cross megabit boundries on the DO). On the Wildflowcr this seems 
acceptable for all but the display bitmap, which would have U) be handled by one of the 
other techniques. On the DO, the display bitmap and perhaps IIT and lOT are exceptions. 
In any case Pilot must be modified so that its space allocation interface supports tlie 
allocation of spaces having suitable properties. 
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c) Real memory is allocated to the buffer so that the vhtual memory of the buffer has 
contiguous real memory allocated underneath it. ITiis has serious negative connotations for 
the real memory allocator in Pilot, which must now become much smaller on the smaller 
machines. It also resurrects the spectre of sandbars which we tried to leave behind in going 
to virtual memory in tlie first place. 

3) If tlie buffer addresses are real, how are tliey bound and what happens when the buffer crosses 
a page boundry? The ideal place to perform tliis translation would seem to be in the routine that 
pins tlie buffer into real memory so that page faults will not occur. There are again three analagous 
cases: 

a) The lOCB is transfonned into n-hl data chained lOCBs where n is the number of page 
crossings. This is the scheme used on the System 360 and System 370. We know from 
those systems that there are some severe problems. First, the data chaining mechanism 
must typically be very fast. The sited systems ran into difficulties when new I/O devices 
and controllers were added post facto to the systems and proved too fast for the existing 
data chaining mechanism. It is not clear that the data chaining can be made significantly 
faster than retranslating the virtual address, case 2a) above. Second, an lOCB blows up into 
several lOCBs, necessatating the allocation of spaces in which they will be placed. 
Interactions between tlie translation process and shortages in this allocation have created 
serious problems, lliird, the time consumed in software translation of the lOCB chain can 
be grossly excessive widiout very careful design. 

b) Buffers may not cross page boundries (discussed above). 

c) Contiguous, real memory is bound under the buffer (discussed above). 

ITiere is nothing to prevent us from adopting a mixed strategy other than our ability to be clear 
about stating that strategy. In any case we should come to some strategy and have it incorporated 
into the PrinceOps before it is released as the basis of an LSI design. 



